                ACCESSING AN IBM MAINFRAME FROM YOUR COMMODORE


   About a year ago, the IBM mainframe shop I work at added facilities for
remote access, so we Systems Programmers could respond to problems off-shift,
without the delay required for us to physically arrive on-site.  While they
provided IBM 3151 terminals and 1200 bps modems for that purpose, I chose not
to take one, and to use my C128 instead.  While this file is intended for 128
owners, 64 owners can also successfully use these techniques, though they'll
need a different program to do so.

   IBM mainframe computers don't use ASCII.  Instead they use their own
encoding scheme, called EBCDIC.  Nobody knows why.  In order to support ASCII
terminals, a "protocol converter" is used.  This is a piece of hardware that
converts the mainframe's synchronous EBCDIC protocol to the asynchronous ASCII
you'll be using, and visa-versa.
   The protocol converter that I'm familiar with is the 3708.  It's the
standard device at this time.  It supports a wide variety of ASCII terminals.
It does not support the Commodore 128, but don't worry.  The 128 isn't a
terminal, it's a computer, and that gives you a freedom not found on any dumb
terminal.
   The first thing you need to do is determine which terminals are supported
by the 3708 you'll be dialing into, in particular, whether it supports the DEC
VT-100.  This is one of the most popular ASCII terminals.  I've never heard of
a 3708 that wasn't configured to support the VT-100, but do make sure.
   While you're talking to the communications people at the mainframe end,
there are two more things you'll need.  First you'll need to know the
"communications parameters" they use.  This consists of three pieces of
information:  The number of data bits, the parity, and the number of stop
bits.  At my shop, we use 7 data bits, Even parity, and 1 stop bit, but
this is by no means universal.  The other thing you'll need from them is a
terminal keyboard map for a VT-100.  This can be found in the appendices of
the 3708 manual.  You need this to know what keystrokes are required to
emulate the 327x PF keys, and other keys that aren't on your Commodore. If you
want to impress these communications people, be sure to refer to the
transmission speed in "bps" (bits per second), not "baud."  (The numbers are
the same.)  They like that sort of thing.  Nobody knows why.
   If the 3708 does support VT-100, you must now find a way to make your
Commodore behave like a VT-100.  The program to do this is called a "terminal
emulator."  A very nice VT-100 emulator for the 128 can be found in two pieces
in LIB 14 of CBMCOM.  The first part, VT100D.SDA, contains the documentation,
and the second, VT100P.SDA, contains the program files.  If new versions are
released, these names may change, so you'll want to check with the Sysops
to be sure you get the most current versions.  Assuming there have been no
changes, just download the two files as PRG files, and RUN them in 128 mode.
They'll automatically "dissolve" into their component parts.  Read the
documentation.
   Now, find the paper where you wrote down the "communications parameters,"
and configure your terminal emulator for those parameters.  3708s are as
touchy about these parameters as communications people are about baud and bps.
   With all this set up, you can now dial your remote access number.  When you
get a CONNECT, hit RETURN, and you should see the first menu, where you
get to choose what type of terminal you're using.  Pick the choice for VT-100,
and you should be on your way.
   Note that if you use a remote access security package, you may have to go
thru some extra steps somewhere along the line.  The security package we use
requires entering a special access code before selecting the terminal type.
You'll have to get that information from your communications or security
people.
   When you do get connected, be aware you'll run into one problem.  It's
not unique to the VT-100 emulator you're using, or to Commodore.  I've used
a VT-100 emulator on a portable IBM clone that displayed the exact same
annoying characteristic.  If the very last character of the very last line
isn't a blank, your screen will scroll up one line.  The mainframe doesn't
know that this happened, so the line it thinks you're working on isn't the
one you think.  As long as you're aware of the problem, you can work around
it, by doing whatever you have to do to get a fresh screen.  If you're using
ISPF, PF2 on the top line, to force a screen split, then repeat, to get back
to your original screen.
   Another annoyance that's not unique to you is transmission speed.  If you're
used to a locally-connected 327x device, 1200 (or even 2400) bps is going to
be maddeningly slow.  You can help matters, though.  The 3708 will only send
you those portions of the screen that have changed.  Again, if you're using
ISPF, you can split the screen to the very minimum you need to do your work.
By keeping the working screen size down, you'll minimize the amount of
changed data that you must receive.
   Once you've got this all working, you too can grin that special grin that
comes when someone asks you what kind of PC you use to access the system,
and you can tell them, "Commodore."  It's best to say it in a very flat voice,
with a very deadpan expression, as though this is the most natural thing in
the world.  You know why.



Ed Flinn
12/12/89
